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REMARKS/ARGUMENTS 

In an Office Action dated December 30, 2008, claims 1, 8-13, 18, 19, 26-31, 36, 
37, 44-49, 54, 55, 62-67 and 72 were rejected under § 103 over Perlman (U.S. Patent No. 
5,844,902) in view of Shah (U.S. Patent No. 7,115,105) and further in view of Suzuki 
(U.S. Patent Appl. Pub. No. 2002/0041594); and the remaining claims were rejected 
under § 103 over Perlman, Shah and Suzuki and various other references. Applicant 
respectfully traverses the § 103 rejections and requests consideration of the following 
arguments. 

Section 103 Rejections 

Claims 1, 8-13, 18, 19, 26-31, 36, 37, 44-49, 54, 55, 62-67 and 72 were rejected 
under § 103 over Perlman in view of Shah and further in view of Suzuki. Claims 2-7, 20- 
25, 38-43 and 56-61 were rejected under § 103 over Perlman in view of Shah, further in 
view of Suzuki and even further in view of Soumiya. Claims 14, 16, 32, 34, 50, 52, 68 
and 70 were rejected under § 103 over Perlman, in view of Shah, further in view of 
Suzuki and even further in view of Fredericks. Claims 15, 33, 51 and 69 were rejected 
under § 103 over Perlman in view of Shah, further in view of Suzuki and even further in 
view of Lee. Claims 17, 35, 53 and 71 were rejected under § 103 over Perlman, in view 
of Shah, further in view of Suzuki and even further in view of Hongal. Applicant 
traverses the rejections. 

Section 103 Rejection Perlman in view of Shah and Suzuki 

Claims 1, 19, 37 and 55 

The claims all require a switch which includes a plurality of interconnected 
switching units coupled to the ports. The Office Action asserts that I/O node 601 is a 
switch that contains multiple switching units. Applicant vigorously traverses this 
statement. 
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Shah deals with bus-bridges and bridge-bridges. Other than a passing reference to 

switch fabric 620, Shah does not discuss switches. Shah states at col. 8, lines 38-49: 

FIG.4 shows the disclosed embodiment of FIG. 2 incor- 
porated into a computer system 600. The computer system 
600 includes CPU nodes 610. I/O nodes 630, and switch 
matrix 620. CPU nodes 610 include the four nodes 611, 612, 
613 and 614. I/O nodes 630 include four I/O nodes 601, 602. 
603 and 604. A switch fabric 620 is connected to CPU nodes 
610 and to I/O nodes 630. The embodiment disclose in FIG. 
2 is shown in FIG. 4 as I/O node 0. hike FIG. 2, I/O node 
0 contains a parent -bridge 230. Parent-bridge 230 is attached 
via child-links 285 to child-bridges 260. The child-bridges 
260, in turn, are connected via grand-child links 295 to buses 
280. Finally, buses 280 are attached to I/O devices 290. It is 

Thus Fig. 2 is the detailed description of the I/O node 601 used in the Office Action. At 

col. 3, lines 65-66 Shah states: "Fig. 2 illustrates a typical multi-bridge architecture 400 

implemented according to the disclosed techniques." Fig. 2 shows I/O devices connected 

via buses to various bus-bridges which in turn are connected via buses to a bridge-bridge, 

in the language of Shah. Thus Shah does not teach or suggest "a plurality of switching 

units coupled to the ports so that a frame traverses multiple switching units in the 

switch." Rather, Shah teaches a multi-level bus-bridge arrangement, which is not similar 

or analogous to a multi-tier switch as specified in the claims. 

The Office Action responds to this argument by stating that multi-tier bus-bridges 

are similar to multi-tier switches because both are used to transfer packets. Applicant 

submits that the statement of the Office Action is misplaced, overly simplistic and too 

general. 

Noting Fig. 4 of Shah, Shah discloses a switch matrix or fabric 620 linking the 
CPU nodes and the I/O nodes. Then the bus-bridge arrangement cited by the Office 
Action is shown only internal to an I/O node. Thus, Shah shows that switch units and 
bus-bridges are separate and non-analogous items. 

The statement that both items transfer packets is overly simplistic and too general. 
The statement simply ignores that the details of operation between serial communications 
as done in Perlman or the interconnected switching units of the present claims bear no 
similarity beyond the fact that both do transfer packets. Wireless data transmissions also 
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transfer packets and so would be considered equally similar to the bus-bridges of Shah 
according to the logic of the Office Action. The level of generality is too high and 
simplistic to be a sufficient reason and does not prove that the bus-bridges of Shah are 
similar to the interconnected switching units of the claims. 

The Office Action also states that Suzuki discloses bus-bridges containing 
switching units. Applicant submits that an analysis of Suzuki shows that the Office 
Action statement is misplaced. Suzuki relates to the IEEE 1394 serial bus network 
protocol (See TJ0002). The bus language used in Suzuki is present only because that is the 
term used in describing 1394. The use of bus in Suzuki describes a serial communication 
scheme. As shown in Fig. 3, 1394 devices are daisy chained. The function of the packet 
switching unit 210 in Fig. 3 is to receive serial packets on one port, sniff them and then 
transfer them out a different port if not related to that particular unit. (See ]]0005) This 
operation is totally unrelated to the parallel bus-bridging in Shah. The only reason the 
term "bus-bridge" is used in Suzuki is it is the term of art used in 1394. It has no 
relationship to the bus-bridge of Shah. Therefore the statement in the Office Action 
about Suzuki is misplaced and erroneous. 

Additionally, one skilled in the art would not combine Perlman and Shah. 
Perlman relates to network switching, particularly to traversing numerous LANs using 
network bridges. Shah relates to bus-level communications with I/O devices using 
parallel buses, not network links, and multiple levels of bus-bridges. The two teachings 
simply are unrelated and could not be combined to form a switch, particularly as Shah 
does not relate to switches. Perlman is for connecting networks. Shah is for connecting 
end I/O devices using buses. Shah only relates to end point operations while Perlman 
relates to entirely intermediary operations. The two teachings are not compatible. 

The Office Action argues, effectively, that Perlman and Shah are analogous and 
properly relied on because both relate to data transmission. As argued similarly above, 
this is simply too general a basis to be sufficient. Carrier pigeons also relate to data 
transmission, so the logic of the Office Action would have carrier pigeons being 
analogous to interconnected switching units. "Data transmission" is simply too general to 
be a proper basis for combination. 
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The stated reason for combination of Perlman and Shah in the Office Action to 
provide central control and connect network devices to a network is also flawed. 
Perlman already connects network devices to a network and further connects networks. 
As to the central control point, this does not appear to be taught by Shah and actually is 
opposed to Perlman and the present claims and their fundamental independent nature. 

Further, when the combination with Perlman is considered, the improperly 
proposed use of the Shah bus-bridges would not include information about each of the 
interconnected switching units, at least because there are no switching units other than the 
element 620 described only as a switching fabric with no further details. Perlman teaches 
adding information to the explorer messages for each bridge connecting two network 
rings. If, contrary to the teachings of Shah and in gross hindsight, the I/O devices of 
Shah were somehow replaced, with no suggestion in the references, with network ports, 
the three bus-bridges of Shah would collapse to be a single bridge in Perlman, which 
would then only identify the bridge between the WAN 24 and the user 40. Thus no 
internal switching unit information would be provided or necessary, as such information 
would not be needed to perform the source routing of Perlman. The only time Perlman 
would add information about each bus-bridge of Shah is if the bus-bridges were 
independent, but then the required included plurality of interconnected switching units 
would not be present. 

The Office Action responds to this argument by referencing Perlman col. 3, lines 

31-33 and col. 5, lines 56-62. The reference to col. 3 is irrelevant as it simply says a 

message has a header with source and destination addresses. Col. 5, lines 56-62 state: 

when received by bridges. As shown in FIG, 2, when a 
bridge receives .120 an explorer message, the bridge modi- 
fies 126 the message by attaching an indication of the LAN 
number and bridge number through which the message has 
passed, as well as any other desired information (e.g., the 
maximum packet size of the links through which the packet 
has passed, or the cost of travelling through those links), and 

Thus, as argued above, Perlman would only add the LAN number and bridge number, the 

bridge simply being the entity between the two LANs. The internal architecture of the 

bridge is irrelevant to an explorer message, as it just needs LAN-bridge-LAN knowledge 

as the bridge would transparently handle any routing needed between the bridge ports. 
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Thus, Perlman would not add any information about the internal structure of the bridge, 
that internal structure being unnecessary. So, even if Perlman were constructed like 
Shah, Perlman would not add its internal information to any packet. Therefore, the 
citations on the Office Action do not provide any further information. Applicant 
continues to submit that the rejection is improper. 

Applicant submits that the proposed combination of Shah is improper and, if 
performed, still does not teach the requirements of claims 1, 19, 37 and 55. 

The Office Action applies Suzuki for adding information to a frame as it traverses 
multiple switching units. The Office Action argues that the channel identifier translation 
done on Suzuki is adding information. Applicant submits that the Office Action 
argument is misplaced. Translation, as done in Suzuki, does not add information, it 
changes information. Different information may be present but not additional 
information. Therefore, Suzuki docs not teach or suggest the position argued by the 
Office Action. Applicant therefore requests reversal of the rejection and allowance of all 
claims. 

Claims 11,29, 47 and 65 

Claims 11, 29, 47 and 65 require the fabric manager to select the port to transmit 
the tracer frame based on normal routing rules. The Office Action cites col. 3, lines 31- 
33 and 54-55 and col. 5, lines 56-64 in rejecting the claims. Applicant traverses the 
rejection. The first cited portions of Perlman relate to ordinary messages. Those normal 
messages do not have any of the required additional information of the claim added to 
them. Thus their operation is not relevant to the claims. 

The col. 5 citation references information added to explorer manages and 

describes the special routing operations for explorer messages. These are the operations 

for explorer messages, not the operations for the normal messages of the col. 3 citations 

and thus the citations are not properly combined. Normal and explorer messages are not 

equivalent and operations applied to explorer messages cannot be transferred to normal 

messages. Referencing Perlman: 

While the above describes the typical mechanism for routing 
packets in a LAN/bridge network, it does not explain how the routes are 
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determined. This is typically accomplished by means of "explorer" 
messages, (col. 5, lines 29-32) 

Through a procedure described below, copies of the explorer 
message are propagated through all of the bridges and LANs in the 
network, exploring every possible route through the network.... (Col. 5, 
lines 36-39) 

Explorer messages are subject to a special procedure when 
received by bridges, (col. 5, lines 55-56) 

... and then forwards 132 the modified version to all connected 
LANs (except the LAN from which the packet was received), (col. 5, 
lines 62-65) 

Thus Perlman itself makes it very explicit that explorer messages do not use the routing 
rules for normal messages. The claims specifically require using routing rules for normal 
frames on the frames which include the added information, which are not the messages of 
col. 3, lines 31-33 but are the explorer messages of col. 5, lines 56-65. Perlman explicitly 
says explorer frames use special procedures. How "normal" frames as in col. 3, lines 31- 
33 are routed is not the subject of the claims, so the entire argument advanced in the 
Office Action is not relevant to the claims. 

Summarizing these arguments, normal messages do use normal routing rules but 
do not have information added in transit. Explorer messages have information added in 
transit but follow special routing rules just for explorer messages. Perlman does not 
suggest any amalgamation of the two messages types as they have very different 
purposes. Adding information to normal messages would only result in producing 
garbled messages, as the intent is to provide the included payload from point A to point 
B. Adding information to the payload makes little sense as that would be adding data. 
Explorer messages are to have the additional information added in transit, but routing the 
explorer messages using normal rules in Perlman which actually result in the complete 
failure of the explorer message. The purpose of the explorer message is to find a route 
because one is not known. As normal routing rules in Perlman require knowing the 
route, by definition an explorer message then could not reach its intended destination. 
Using the explorer message routing rules for normal messages would result in a flood of 
traffic in the network, probably a totally overwhelming flood. Thus one would not and 
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cannot mix and match normal and explorer messages as apparently being done in the 
Office Action. 

The Office Action argues that the routing rules for the explorer messages are 
"normal routing rules" for explorer messages. Applicant has clarified the claims to 
indicate the use of routing rules for normal frames. As Perlman uses different routing 
rules for the special explorer frames, the arguments made above still apply and the 
argument in the Office Action is no longer relevant. 

Applicant submits that claims 1 1, 29, 47 and 65 are allowable. 

Claims 12, 30, 48 and 66 

Claims 12, 30, 48 and 66 require the frames to include source routing information 
and that the ports transmit them based on the source routing information. The Office 
Action cites col. 3, lines 31-33 and 54-55 and col. 5, lines 56-64 in rejecting the claims. 
Applicant traverses the rejection. The first cited portions relate to ordinary or normal 
messages. Those normal messages do not have any of the required additional 
information of the claim added to them. Thus their operation is not relevant to the 
claims. Further, they do not relate to the explorer messages discussed at col. 5, lines 29 
to col. 6, line 8. Perlman, at col. 5, lines 63-65, specifically notes that the modified 
explorer message is forwarded to all connected LANs, except the source LAN. Thus 
Perlman indicates that explorer messages use very special routing rules, not the source 
routing required by the claims. 

Again the Office Action appears to combine message types that Perlman 
specifically indicates are different types and behave differently. 

Applicant submits that claims 12, 30, 48 and 66 are allowable. 

Section 103 Rejection Perlman in view of Shah, Suzuki and Fredericks 

Claims 14, 32, 50 and 68 

Claims 14, 32, 50 and 68 require the frame to be destination addressed to a well 
known address and the fabric manager to retrieve the true destination address from the 
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payload. The Office Action combines Perlman and Fredericks to form the rejection. 
Applicant traverses the rejection. 

Applicant first notes that the Perlman explorer messages are specifically 
addressed to the desired end point. To change them to being addressed to a well known 
address is not taught or suggested by Perlman and would completely destroy the 
fundamental operation of the Perlman explorer message. This is clearly a hindsight 
combination and goes against the teachings of the reference. 

Perlman is a series of ring networks connected by bridges and routed using source 
routing. The Fibre Channel switch of Fredericks has no rings and does not use source 
routing but rather routes using FSPF based on the destination address. The references 
employ totally different techniques, sufficiently different than Applicant submits that the 
only place the Office Action could have looked to gain the required knowledge is 
Applicant's own disclosure, which has been previously admitted as improper. Applicant 
requests some positive teaching in the references that teaches such a drastic redesign of 
each reference. 

The Office Action argues that all obviousness judgments include reconstruction 
based on hindsight reasoning and thus any knowledge within the ordinary skill is proper 
for a reconstruction. Applicants submit that this reconstruction is not proper when the 
two references use fundamentally different techniques and to convert from a first 
reference technique to a second reference technique requires completely scrapping (i.e. 
destroying) the operation of the first reference, the combination is not proper. Such is the 
case here. The two routing schemes are fundamentally opposed and use of Fredericks 
with Perlman would completely destroy the entire routing scheme of Perlman. Therefore, 
the combination is improper. 

Fredericks relates to Fibre Channel RNID ELS messages. Referencing col. 6, 
lines 21-34, the addressing of the message is described. It states the message is 
preferably sent to the nearest neighbor node, though it also notes that any node can be 
addressed. The fabric controller well known address is only used if the nearest neighbor 
node is a fabric node, a special instance. Otherwise the message is addressed directly to 
the other node. Fredericks does not mention anything about retrieving the true 
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destination address from the frame payload, and would not, as the frame is addressed to 
the relevant item. The Office Action appears to equate the command code in the RNID 
ELS to the required true destination address, but that equivalence is simply incorrect 
when the meaning of true destination address is construed properly. 

The Office Action continues to contend that the command code in the RNID ELS 
message is somehow a destination address. The command code identifies the particular 
Extended Link Service, such as 03 for N Port Login, 05 for Logout, and 78 for Request 
Node Identification Data (RNID). See the FC-FS standard, Chapter 12 for a more 
detailed explanation. 

The Office Action also continues to argue that Table 1 shows the destination ID is 
retrieved from the payload. As stated, Table 1 simply shows selected header values to 
identify that the packet is an ELS command. Table 1 does not show anything about 
retrieving destination addresses from payloads. 

The Office Action also references col. 5, lines 9-10. However, these lines are not 
relevant because they describe messages being returned from the destination. They are 
wholly different packets from the packet being sent to the destination. Thus, their content 
is not relevant. 

Applicant submits the rejection is improper and that the claims are allowable. 
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CONCLUSION 

Based on the above remarks Applicants respectfully submit that all of the present 
claims are allowable. Reconsideration is respectfully requested. 

Respectfully submitted, 
Date: April 30, 2009 /Keith Lutsch/ 
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